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Requirements for Labeled NFS 
Abstract 


This memo outlines high-level requirements for the integration of 
flexible Mandatory Access Control (MAC) functionality into the 
Network File System (NFS) version 4.2 (NFSv4.2). It describes the 
level of protections that should be provided over protocol components 
and the basic structure of the proposed system. The intent here is 
not to present the protocol changes but to describe the environment 
in which they reside. 


Status of This Memo 


This document is not an Internet Standards Track specification; it is 
published for informational purposes. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Not all documents 


approved by the IESG are a candidate for any level of Internet 
Standard; see Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc7204. 
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document authors. All rights reserved. 


This document is subject to BCP 78 and the IETF Trust’s Legal 
Provisions Relating to IETF Documents 
(http://trustee.ietf.org/license-info) in effect on the date of 
publication of this document. Please review these documents 
carefully, as they describe your rights and restrictions with respect 
to this document. Code Components extracted from this document must 
include Simplified BSD License text as described in Section 4.e of 
the Trust Legal Provisions and are provided without warranty as 
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1. Introduction 


Mandatory Access Control (MAC) systems (as defined in [RFC4949]) have 
been mainstreamed in modern operating systems such as Linux, FreeBSD, 
and Solaris. MAC systems bind security attributes to subjects 
(processes) and objects within a system. These attributes are used 
with other information in the system to make access control 
decisions. 


Access control models such as Unix permissions or Access Control 
Lists (ACLs) are commonly referred to as Discretionary Access Control 
(DAC) models. These systems base their access decisions on user 
identity and resource ownership. In contrast, MAC models base their 
access control decisions on the label on the subject (usually a 
process) and the object it wishes to access. These labels may 
contain user identity information but usually contain additional 
information. In DAC systems, users are free to specify the access 
rules for resources that they own. MAC models base their security 
decisions on a system-wide policy established by an administrator or 
organization that the users do not have the ability to override. DAC 
systems offer some protection against unauthorized users running 
malicious software. However, even an authorized user can execute 
malicious or flawed software with those programs running with the 
full permissions of the user executing it. Inversely, MAC models can 
confine malicious or flawed software and usually act at a finer 
granularity than their DAC counterparts. 


Besides describing the requirements, this document records the 
functional requirements for the client imposed by the preexisting 
security models on the client. This document may help those outside 
the NFS community understand those issues. 


2. Definitions 


Foreign Label: a label in a format other than the format that a MAC 
implementation uses for encoding. 


Label Format Specifier (LFS): an identifier used by the client to 
establish the syntactic format of the security label and the 
semantic meaning of its components. 

MAC-Aware: a server that can transmit and store object labels. 

MAC-Functional: a client or server that is Labeled NFS enabled. 


Such a system can interpret labels and apply policies based on the 
security system. 
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Multi-Level Security (MLS): a traditional model where objects are 
given a sensitivity level (Unclassified, Secret, Top Secret, etc.) 
and a category set [RH_MLS]. 


Object: a passive resource within the system that we wish to 
protect. Objects can be entities such as files, directories, 
pipes, sockets, and many other system resources relevant to the 
protection of the system state. 


Policy Identifier (PI): an optional part of the definition of a 
Label Format Specifier. The PI allows clients and servers to 


identify specific security policies. 


Subject: an active entity, usually a process, that is requesting 
access to an object. 


2.1. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", “SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 

3. Requirements 
The following initial requirements have been gathered from users and 
developers, and from previous development efforts in this area such 
as the Distributed Trusted Operating System [DTOS] and the NSA’s 


experimental NFSv3 enhancements [SENFSv3]. 


3.1. General 


A mechanism is required to provide security attribute information to 


NFSv4 clients and servers. This mechanism has the following 
requirements: 
(1) Clients MUST be able to convey to the server the client’s 


privileges, i.e., the subject, for making the access request. 
The server may provide a mechanism to enforce MAC policy based 
on the requesting client’s privileges. 


(2) Servers MUST be able to store and retrieve the security 
attribute of exported files as requested by the client. 


(3) Servers MUST provide a mechanism for notifying clients of 
attribute changes of files on the server. 


(4) Clients and Servers MUST be able to negotiate Label Formats and 
provide a mechanism to translate between them as needed. 
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3.2. Security Services 


Labeled NFS or the underlying system on which the Labeled NFS 
operates MUST provide the following security services for all NFSv4.2 
messaging: 


o Authentication 
o Integrity 
o Privacy 


Mechanisms and algorithms used in the provision of security services 
MUST be configurable so that appropriate levels of protection may be 
flexibly specified per mandatory security policy. 


Strong mutual authentication is required between the server and the 
client for Full Mode operation (Section 4.1). 


MAC security labels and any related security state MUST always be 
protected by these security services when transferred over the 
network, as MUST the binding of labels and state to associated 
objects and subjects. 


Labeled NFS SHOULD support authentication on a context granularity so 
that different contexts running on a client can use different 
cryptographic keys and facilities. 


3.3. Label Encoding, Label Format Specifiers, and Label Checking 
Authorities 


Encoding of MAC labels and attributes passed over the network MUST be 
specified in a complete and unambiguous manner while maintaining the 
flexibility of MAC implementations. To accomplish this, the labels 
MUST consist of a format-specific component bound with a Label Format 
Specifier (LFS). The LFS component provides a mechanism for 
identifying the structure and semantics of the opaque component. 
Meanwhile, the opaque component is the security label that will be 
interpreted by the MAC models. 


MAC models base access decisions on security attribute privileges 
bound to subjects and objects, respectively. With a given MAC model, 
all systems have semantically coherent labeling -- a security label 
MUST always mean exactly the same thing on every system. While this 
may not be necessary for simple MAC models, it is recommended that 
most Label Formats assigned an LFS incorporate semantically coherent 
labeling into their Label Format. 
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Labeled NFS SHOULD define an initial negotiation scheme with the 
primary aims of simplicity and completeness. This is to facilitate 
practical deployment of systems without being weighed down by complex 
and overgeneralized global schemes. Future extensibility SHOULD also 
be taken into consideration. 


Labeled NFS MUST provide a means for servers and clients to identify 
their LFSs for the purposes of authorization, security service 
selection, and security label interpretation. 


Labeled NFS MUST provide a means for servers and clients to identify 
their mode of operation (see Section 4). 


A negotiation scheme SHOULD be provided, allowing systems from 
different Label Formats to agree on how they will interpret or 
translate each other’s foreign labels. Multiple concurrent 
agreements may be current between a server and a client. 


All security labels and related security state transferred across the 
network MUST be tagged with a valid LFS. 


If the LFS supported on a system changes, the system SHOULD 
renegotiate agreements to reflect these changes. 


If a system receives any security label or security state tagged with 
an LFS it does not recognize or cannot interpret, it MUST reject that 
label or state. 


NFSv4.2 includes features that may cause a client to cross an LFS 
boundary when accessing what appears to be a single file system. If 
LFS negotiation is supported by the client and the server, the server 
SHOULD negotiate a new, concurrent agreement with the client, acting 
on behalf of the externally located source of the files. 


3.4. Labeling 


Implementations MUST validate security labels supplied over the 
network to ensure that they are within a set of labels permitted from 
a specific peer and, if not, reject them. Note that a system may 
permit a different set of labels to be accepted from each peer. 


3.4.1. Client Labeling 


At the client, labeling semantics for NFS mounted file systems MUST 
remain consistent with those for locally mounted file systems. In 
particular, user-level labeling operations local to the client MUST 
be enacted locally via existing APIs, to ensure compatibility and 
consistency for applications and libraries. 
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Note that this does not imply any specific mechanism for conveying 
labels over the network. 


When an object is newly created by the client, it will calculate the 
label for the object based on its policy. Once that is done, it will 
send the request to the server, which has the ability to deny the 
creation of the object with that label based on the server’s policy. 
In creating the file, the server MUST ensure that the label is bound 
to the object before the object becomes visible to the rest of the 
system. This ensures that any access control or further labeling 
decisions are correct for the object. 


3.4.2. Server Labeling 


The server MUST provide the capability for clients to retrieve 
security labels on all exported file system objects where possible. 
This includes cases where only in-core and/or read-only security 
labels are available at the server for any of its exported file 
systems. 


The server MUST honor the ability for a client to specify the label 
of an object on creation. If the server is MAC enabled, it may 
choose to reject the label specified by the client, due to 
restrictions in the server policy. The server SHOULD NOT attempt to 
find a suitable label for an object in the event of different 
labeling rules on its end. The server is allowed to translate the 
label but MUST NOT change the semantic meaning of the label. 


3.5. Policy Enforcement 


The MAC-Functional client determines if a process request is sent to 
the remote server. Upon a successful response from the server, it 
must use its own policies on the object’s security labels to 
determine if the process can be given access. The client SHOULD NOT 
need to be cognizant of whether the server is a Limited Server or is 
fully MAC-Functional. 


3.5.1. Client Enforcement 


The client MUST apply its own policy to remotely located objects, 
using security labels for the objects obtained from the server. It 
MUST be possible to configure the maximum length of time a client may 
cache state regarding remote labels before revalidating that state 
with the server. 
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If the server’s policy changes, the client MUST flush all object 
state back to the server. The server MUST ensure that any flushed 
state received is consistent with current policy before committing it 
to stable storage. 


Any local security state associated with cached or delegated objects 
MUST also be flushed back to the server when any other state of the 
objects is required to be flushed back. 


The implication here is that if the client holds a delegation on an 
object, then it enforces policy to local changes based on the object 
label it got from the server. When it tries to commit those changes 
to the server, it SHOULD be prepared for the server to reject those 
changes based on the policies of the server. 


3.5.2. Server Enforcement 


A MAC-Functional server MUST enforce its security policy over all 
exported objects, for operations that originate both locally and 
remotely. 


Requests from authenticated clients MUST be processed using security 
labels and credentials supplied by the client as if they originated 
locally. 


As with labeling, the system MUST also take into account any other 
volatile client security state, such as a change in process security 
context via dynamic transition. Access decisions SHOULD also be made 
based upon the current client security label accessing the object, 
rather than the security label that opened it, if different. 


The server SHOULD recall delegation of an object if the object’s 
security label changes. 


3.6. Namespace Access 
The server SHOULD provide a means to authorize selective access to 


the exported file system namespace based upon client credentials and 
according to security policy. 


This is a common requirement of MLS-enabled systems, which often need 
to present selective views of namespaces based upon the clearances of 
the subjects. 
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3.7. Upgrading Existing Server 


Note that under the MAC model, all objects MUST have labels. 
Therefore, if an existing server is upgraded to include Labeled NFS 
support, then it is the responsibility of the security system to 
define the behavior for existing objects. 


4. Modes of Operation 


In a Labeled NFS client and server interaction, we can describe three 
modes of operation: 


1. Full 
2. Limited Server 
3. Guest 


These modes arise from the level of MAC functionality in the clients 
and servers. The clients can be non-MAC-Functional and 
MAC-Functional. The servers can be non-MAC-Functional, MAC-Aware, 
and MAC-Functional. 


A MAC-Functional client MUST be able to determine the level of MAC 
functionality in the server. Likewise, a MAC-Functional server MUST 
be able to determine whether or not a client is MAC-Functional. As 
discussed in Section 3.3, the protocol MUST provide for the client 
and server to make those determinations. 


4.1. Full Mode 


The server and the client have mutually recognized MAC functionality 
enabled, and full Labeled NFS functionality is extended over the 
network between both client and server. 


An example of an operation in Full Mode is as follows. On the 
initial lookup, the client requests access to an object on the 
server. It sends its process security context over to the server. 


The server checks all relevant policies to determine if that process 
context from that client is allowed to access the resource. Once 
this has succeeded, the object, with its associated security 
information, is released to the client. Once the client receives the 
object, it determines if its policies allow the process running on 
the client access to the object. 
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On subsequent operations where the client already has a handle for 
the file, the order of enforcement is reversed. Since the client 
already has the security context, it may make an access decision 
against its policy first. This enables the client to avoid sending 
requests to the server that it knows will fail, regardless of the 
server’s policy. If the client passes its policy checks, then it 
sends the request to the server, where the client’s process context 
is used to determine if the server will release that resource to the 
client. If both checks pass, the client is given the resource and 
everything succeeds. 


In the event that the client does not trust the server, it may opt to 
use an alternate labeling mechanism, regardless of the server’s 
ability to return security information. 


4.2. Limited Server Mode 
The server is MAC-Aware, and the clients are MAC-Functional. The 
server can store and transmit labels. It cannot enforce labels. The 


server MUST inform clients when an object label changes for a file 
the client has open. 


In this mode, the server may not be aware of the format of any of its 
object labels. Indeed, it may service several different security 
models at the same time. A client MUST process foreign labels as 
discussed in Section 3.3. As with the Guest Mode, this mode’s level 
of trust can be degraded if non-MAC-Functional clients have access to 
the server. 


4.3. Guest Mode 
Only one of the server or client is MAC-Functional enabled. 


In the case of the server only being MAC-Functional, the server 
enforces its policy and may selectively provide standard NFS services 
to clients based on their authentication credentials and/or 
associated network attributes (e.g., IP address, network interface) 
according to security policy. The level of trust and access extended 
to a client in this mode is configuration-specific. 


In the case of the client only being MAC-Functional, the client MUST 
operate as a standard NFSv4.2 (see [NFSv4_2]) client and SHOULD 
selectively provide processes access to servers based upon the 
security attributes of the local process, and network attributes of 
the server, according to policy. The client may also override 
default labeling of the remote file system based upon these security 
attributes or other labeling methods such as mount point labeling. 
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In other words, the Guest Mode is standard NFSv4.2 over the wire, 
with the MAC-Functional system mapping the non-MAC-Functional 
system’s processes or objects to security labels based on other 
characteristics in order to preserve its MAC guarantees. 


5. Use Cases 


MAC labeling is meant to allow NFSv4.2 to be deployed in site- 
configurable security schemes. The LFS and opaque data scheme allows 
for flexibility to meet these different implementations. In this 
section, we provide some examples of how NFSv4.2 could be deployed to 
meet existing needs. This is not an exhaustive listing. 


5.1. Full MAC Labeling Support for Remotely Mounted File Systems 


In this case, we assume a local networked environment where the 
servers and clients are under common administrative control. All 
systems in this network have the same MAC implementation and 
semantically identical MAC security labels for objects (i.e., labels 
mean the same thing on different systems, even if the policies on 
each system may differ to some extent). Clients will be able to 
apply fine-grained MAC policy to objects accessed via NFS mounts and 
thus improve the overall consistency of MAC policy application within 
this environment. 


An example of this case would be where user home directories are 
remotely mounted, and fine-grained MAC policy is implemented to 
protect, for example, private user data from being read by malicious 
web scripts running in the user’s browser. With Labeled NFS, fine- 
grained MAC labeling of the user’s files will allow the MAC policy to 
be implemented and provide the desired protection. 


5.2. MAC Labeling of Virtual Machine Images Stored on the Network 


Virtualization is now a commonly implemented feature of modern 
operating systems, and there is a need to ensure that MAC security 
policy is able to protect virtualized resources. A common 
implementation scheme involves storing virtualized guest file systems 
on a networked server; these file systems are then mounted remotely 
by guests upon instantiation. In this case, there is a need to 
ensure that the local guest kernel is able to access fine-grained MAC 
labels on the remotely mounted file system so that its MAC security 
policy can be applied. 


Haynes Informational [Page 11] 


RFC 7204 ReqLabeledNFS April 2014 


5.3. Simple Security Label Storage 


In this case, a mixed and loosely administered network is assumed, 
where nodes may be running a variety of operating systems with 
different security mechanisms and security policies. It is desired 
that network file servers be simply capable of storing and retrieving 
MAC security labels for clients that use such labels. The Labeled 
NFS protocol would be implemented here solely to enable transport of 
MAC security labels across the network. It should be noted that in 
such an environment, overall security cannot be as strongly enforced 
as when the server is also enforcing and that this scheme is aimed at 
allowing MAC-capable clients to function with its MAC security policy 
enabled rather than perhaps disabling it entirely. 


5.4. Diskless Linux 


A number of popular operating system distributions depend on a 
Mandatory Access Control (MAC) model to implement a kernel-enforced 
security policy. Typically, such models assign particular roles to 
individual processes, which limit or permit performing certain 
operations on a set of files, directories, sockets, or other objects. 
While the enforcing of the policy is typically a matter for the 
diskless NFS client itself, the file system objects in such models 
will typically carry MAC labels that are used to define policy on 


access. These policies may, for instance, describe privilege 
transitions that cannot be replicated using standard NFS ACL-based 
models. 


For instance, on a SYSV-compatible system (see [SYSV]), if the ‘init’ 
process spawns a process that attempts to start the ’NetworkManager’ 
executable, there may be a policy that sets up a role transition if 
the 'init” process and 'NetworkManager” file labels match a 
particular rule. Without this role transition, the process may find 
itself having insufficient privileges to perform its primary job of 
configuring network interfaces. 


In setups of this type, a lot of the policy targets (such as sockets 
or privileged system calls) are entirely local to the client. The 
use of RPCSEC_GSSv3 ([RPC_SEC]) for enforcing compliance at the 
server level is therefore of limited value. The ability to 
permanently label files and have those labels read back by the client 
is, however, crucial to the ability to enforce that policy. 
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5.5. Multi-Level Security 


In an MLS system, objects are generally assigned a sensitivity level 
and a set of compartments. The sensitivity levels within the system 
are given an order ranging from lowest to highest classification 
level. Read access to an object is allowed when the sensitivity 
level of the subject "dominates" the object it wants to access. This 
means that the sensitivity level of the subject is higher than that 
of the object it wishes to access and that its set of compartments is 
a superset of the compartments on the object. 


The rest of this section will just use sensitivity levels. In 
general, the example is a client that wishes to list the contents of 
a directory. The system defines the sensitivity levels as 
Unclassified (U), Secret (S), and Top Secret (TS). The directory to 
be searched is labeled Top Secret, which means access to read the 
directory will only be granted if the subject making the request is 
also labeled Top Secret. 


5.5.1. Full Mode - MAC-Functional Client and Server 


In the first part of this example, a process on the client is running 
at the Secret level. The process issues a readdir() system call, 
which enters the kernel. Before translating the readdir() system 
call into a request to the NFSv4.2 server, the host operating system 
will consult the MAC module to see if the operation is allowed. 

Since the process is operating at Secret and the directory to be 
accessed is labeled Top Secret, the MAC module will deny the request 
and an error code is returned to user space. 


Consider a second case where instead of running at Secret the process 


is running at Top Secret. In this case, the sensitivity of the 
process is equal to or greater than that of the directory, so the MAC 
module will allow the request. Now the readdir() is translated into 


the necessary NFSv4.2 call to the server. For the remote procedure 
call (RPC) request, the client is using the proper credential to 
assert to the server that the process is running at Top Secret. 


When the server receives the request, it extracts the security label 
from the RPC session and retrieves the label on the directory. The 
server then checks with its MAC module to see if a Top Secret process 
is allowed to read the contents of the Top Secret directory. Since 
this is allowed by the policy, then the server will return the 
appropriate information back to the client. 
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In this example, the policy on both the client and server is the 
same. In the event that they were running different policies, a 
translation of the labels might be needed. In this case, it could be 
possible for a check to pass on the client and fail on the server. 
The server may consider additional information when making its policy 
decisions. For example, the server could determine that a certain 
subnet is only cleared for data up to Secret classification. If that 
constraint was in place for the example above, the client would still 
succeed, but the server would fail, since the client is asserting a 
label that it is not able to use (Top Secret on a Secret network). 


.2. MAC-Functional Client 


In these scenarios, the server is either non-MAC-Aware or MAC-Aware. 
The actions of the client will depend on whether it is configured to 
treat the MAC-Aware server in the same manner as the non-MAC-Aware 
one. That is, does it utilize the approach presented in Section 4.3, 
or does it allow the MAC-Aware server to return labels? 


With a client that is MAC-Functional and using the example in the 
previous section, the result should be the same. The one difference 
is that all decisions are made on the client. 


5.5.2.1. MAC-Aware Server 


A process on the client labeled Secret wishes to access a directory 
labeled Top Secret on the server. This is denied, since Secret does 
not dominate Top Secret. Note that there will be NFSv4.2 operations 
issued that return an object label for the client to process. 


Note that in this scenario, all of the clients must be 
MAC-Functional. A single client that does not do its access control 
checks would violate the model. 


5.5.2.2. Non-MAC-Aware Server 


A process on the client labeled Secret wishes to access a directory 
that the client’s policies label as Top Secret on the server. This 
is denied, since Secret does not dominate Top Secret. Note that 
there will not be NFSv4.2 operations issued. If the process had a 
Top Secret process label instead of Secret, the client would issue 
NFSv4.2 operations to access the directory on the server. 
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5.5.3. MAC-Functional Server 


With a MAC-Functional server and a client that is not, the client 
behaves as if it were in a normal NFSv4.2 environment. Since the 
process on the client does not provide a security attribute, the 
server must define a mechanism for labeling all requests from a 
client. Assume that the server is using the same criteria used in 
the first example. The server sees the request as coming from a 
subnet that is a Secret network. The server determines that all 
clients on that subnet will have their requests labeled with Secret. 
Since the directory on the server is labeled Top Secret and Secret 
does not dominate Top Secret, the server would fail the request with 
NFS4ERR_ACCESS. 


6. Security Considerations 
6.1. Trust Needed for a Community 


Labeled NFS is a transport mechanism for labels, a storage 
requirement for labels, and a definition of how to interpret labels. 
It defines the responsibilities of the client and the server in the 
various permutations of being MAC-Functional. It does not, however, 
dictate in any manner whether assumptions can be made about other 
entities in the relationship. For example, it does not define 
whether a MAC-Functional client can demand that a MAC-Aware server 
only accept requests from other MAC-Functional clients. That is a 
policy based on a MAC model, and this document does not impose 
policies on systems. 


As the requirement is a policy, it can be met with the use of a MAC 
model. Let L be an LFS that implements the Limited Server mode, 
i.e., a MAC-Aware server connected to MAC-Functional clients. Then 
a new LFS, L’, can be created that has the additional policy that 
the MAC-Aware server MUST NOT accept any requests from a 
non-MAC-Functional client. 


6.2. Guest Mode 


When either the client or server is operating in Guest Mode, it is 
important to realize that one side is not enforcing MAC protections. 
Alternate methods are being used to handle the lack of MAC support, 
and Care should be taken to identify and mitigate threats from 
possible tampering outside of these methods. 
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MAC-Functional Client Configuration 


We defined a MAC model as an access control decision made on a system 
in which normal users do not have the ability to override policies 
(see Section 1). If the process labels are created solely on the 
client, then if a malicious user has sufficient access on that 
client, the Labeled NFS model is compromised. Note that this is no 
different from: 


o current implementations in which the server uses policies to 
effectively determine the object label for requests from the 
client, or 


o local decisions made on the client by the MAC security system. 
Either the server must explicitly trust the client (as in [SENFSv3]) 
or the MAC model should enforce that users Cannot override policies, 


perhaps via an externally managed source. 


Once the labels leave the client, they can be protected by the 
transport mechanism as described in Section 3.2. 
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